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14 June 1979 

25X1 A 


MEMORANDUM FOR: 
FROM : 

SUBJECT : 

REFERENCE : 


Chief, Management Staff, ODP 
NFAC ADP Control Officer 

Comments on Agency Review of Proposed Federal 
Information Processing Standards Publication 

Your memo, same subject, dated 30 May 1979 


25X1 A 


1. In response to your request in the cited reference, several 
NFAC offices (OCR, OER, OWI, OGCR) have reviewed the FIBS PUBS materials. 
Attached are the office submissions. 


2. In addition to these comments, I would like to express my con- 
cern about the resource implications that a rigid Agency adherence to 
the FIBS PUBS might imply. Recently, our components have been besieged 
by requests from the records management area, security, audit staff, 
etc. for information about their ADP activities. NFAC has been able to 
provide the information, but not without sacrifice. The FIBS PUBS 
material makes reference to "a mechanism for measuring adherence to and 
assessing the impact of standards." How can Department of Commerce 
effectively monitor the Agency's ADP activities--especially in our 
highly classified activities? Would this type of monitoring be appro- 
priate? What are the resource implications? 

3. A second area of concern is the potential loss of efficiency in 
our ADP activities that might occur without a common sense application 

of any standard. I believe any standards that further impede our ability 
to develop or procure ADP software/ hardware would be intolerable while 
standards which streamline these activities welcomed. 


4. NFAC stands ready to review the FIBS PUBS as they become avail- 


able. If T may h 
extension 


e of any further help on this matter, please call on 


Attachments 
As stated 


25X1 A 
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STATINTL 


11 June 1979 


MEMORANDUM FOR: 


STATINTL 

NbAU AUP Control Officer 

FROM 

• 

• 

OCR ADP Control Officer 

SUBJECT 

: Comments on Agency Review of Proposed Federal 
Information Processing Standards 

REFERENCE 

: Your memo to OCR, OWI, OER and OGCR ADP/COs, dated 
4 June 79, same subject 


1. OCR has no comments at this juncture in the Computer Science 
and Technology Program Plan. 


2. OCR supports the establishment of data processing standards 
where such standards do not interfere with the efficiency' of the 
activities they encompass. We look forward to the opportunity to 
review and comment on individual standards as they become available in 
draft form. 


REG/ga 


STATINTL 
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15 June 1979 


MEMORANDUM FOR: NFAC ADP Control Officer 


FROM 


OER ADP Control Officer 


SUBJECT 

STATINTL 


Comments on Proposed Federal Information 
Processing Standards 


1. In response to your request to review that small 
mountain of information you sent me on proposed information 
processing standards, I read the "Computer Science and 
Technology Plan" fairly carefully and skimmed over the 
"Guide for the Implementation of Federal Information Proces- 
sing Standards for Acquisit ion and Design of Computer Products 


and Services." 


of our Development and Analysis 


Center also reviewed the material. We have comments that 
address three broad areas of concern: (1) cost, (2) security, 
and (3) technical factors. 


Cost Considerations 

2 . One of our major concerns with this program is 
its cost. We are not talking only about the funded costs 
mentioned in the Plan, but of the indirect costs as well. 

It cost us something to review all the material you sent us, 
for example, and it will cost us a great deal more in terms 
of manhours diverted from productive work to implement such 
a program. It also will cost us a considerable amount to 
report on our adherence if the program is put into place. 

I hope the proponents of this program are prepared to 
incorporate the additional personnel ceilings and money 
for us to do these things in their budget. It will cost 
considerably more than the $20 mentioned in the Plan. 


3. We are pleased that the program includes cost/ 
benefit analysis for each standard or group of standards. 
Unless that analysis addresses all the indirect costs 
mentioned above, it will be of no value. 
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4. There is another type of cost that concerns us — 
the cost of converting existing programs to run under the 
new standards. This cost could well dwarf the costs of 
setting up and administering the standards program. 

5. Our final concern about cost is what standards 
will do to our procurement costs. There is a good chance 
that many firms that manufacture high-quality, low-cost 
hardware will simply ignore a government standard because 
the government does not represent a large portion of their 
sales and because the manufacturers cannot afford the major 
changes that standards might imply. We may be forced to 
buy inferior equipment because it adheres to somebody's 
arbitrary conception of a standard. 

Security Considerations 

6. Our major concern about security is the prospect 

of having the Department of Commerce monitor Agency computer 
activities. Is this a serious prospect? Does Commerce 
have people who are cleared for this information? Do 
they have a need to know? If, by some enormous stretch 
of the imagination. Commerce does acquire a monitoring 
responsibility over the Agency, I hope funding will be 
adequate to cover all the costs of clearing personnel and 
maintaining secure facilities at Commerce. The f undine? 
should also include a substantial amount to cover the 
hospitalization of our own computer security people when 
they hear about this program. 

Technical Considerations 

7. Last, but not least, we are concerned about the 
technical implications of these proposed standards. For 
example, the standards clearly express a preference for an 
ASCII standard that would preclude other codes, like EBCDIC. 
We do not like the ASCII collating sequence for one thing. 

We also feel that mainframe architecture and system software 
should be designed for efficiency, and not for adherence to 
a standard. The material we reviewed implies that ASCII 
already is a world standard, but we take exception to that 
view. We process much tape-based data from foreign 
countries and have found virtually all of it to be EBCDIC. 



Approved For Release 2002/06/18 : CIA-RDP84-00933R0002001 5001 1-4 



Approved For please 2002/06/18 : CIA-RDP84-00933W8f00200150011-4 


8. Another ASCII related question is whether we could 
buy IBM equipment any longer. It seems absurd to foreclose 
our option to buy products from the world's leading computer 
manufacturer for the sake of adhering to a set of standards 
that are questionable on other grounds. 

9. We are concerned that there is no mention of 
PL/I in the proposed standards. Does this imply that 
those drafting standards are prepared to exclude PL/I as an 
acceptable compiler? PL/I can be an impediment to competitive 
bidding/ so we suspect proponents of standards wish it 

did not exist. We rely on PL/I extensively, and find it 
a most efficient and productive language for our purposes. 

The loss of PL/I would cause a severe degradation of our 
programming productivity, and an even more severe degradation 
of the ODP batch processing systems if we were to turn to 
FORTRAN, for example. 

10. We are also concerned about what standards will 

do to the quality of hardware and software that is retained 
under a standard. We are afraid what we will get is the 
lowest common denominator, that is, the version that has 
only the common elements of all existing versions and none 
of the enhancements that make one vers ion superior to others 
for a given application. A standard in FORTRAN, for example, 
would not use the full capacity of the language as we now 
see it. ANS FORTRAN has no (END=, no INTEGER*2, no direct 
access, no hex constants, no implicit typing of variables, 
and no format codes. These are just a few examples of how 
standards can degrade a programming language. One can 
expect similar degradation wherever standards are applied. 

*■ 

11. You may gather from these comments that we do not 
enthusiastically embrace the concept of standards. We do not. 

If you have any questions about these comm ents, or can 

think of any way for us to get part of the I I STATINTL 

budget for this program in return for our time spent in 
evaluating it, please contact me on extension I I STATINTL 


STATINTL 
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